GermanWikipedia - /page/entry.mu

Micron Document

<!DOCTYPE html>

<title>Embedded Software Engineering</title>

</head>

<h1 id="firstHeading" class="firstHeading mw-first-heading"><span class="mw-page-title-main">Embedded Software Engineering</span></h1>

</header>

</div>

<div id="mw-content-text" class="mw-body-content mw-content-ltr" lang="de" dir="ltr"><div class="mw-content-ltr mw-parser-output" lang="de" dir="ltr"><p>Der Begriff <b>Embedded Software Engineering</b> setzt sich zusammen aus den Begriffen <i>Embedded Systems</i> (deutsch „<a href="Eingebettetes_System" title="Eingebettetes System">eingebettete Systeme</a>“) und <i>Software Engineering</i>, (deutsch „<a href="Softwaretechnik" title="Softwaretechnik">Softwaretechnik</a>“). Ein <a href="Eingebettetes_System" title="Eingebettetes System">eingebettetes System</a> ist ein binärwertiges digitales System (Computersystem), das in ein umgebendes technisches System eingebettet ist und mit diesem in Wechselwirkung steht. Dabei hat das Computersystem die Aufgabe, das System, in das es eingebettet ist, zu steuern, zu regeln oder zu überwachen. Die Softwaretechnik beschäftigt sich mit der Herstellung von Software, also der Entwicklung und dem Betrieb von Programmen und der Organisation und Modellierung der zugehörigen Datenstrukturen.<sup id="cite_ref-balzert_1-0" class="reference"><a href="#cite_note-balzert-1"><span class="cite-bracket">[</span>1<span class="cite-bracket">]</span></a></sup>

</p><p>Das Besondere der eingebetteten Systeme besteht in ihrer Eigenschaft als „universeller Systemintegrator“. Die technischen Systeme werden dabei durch interagierende Komponenten geformt. Die hohe Zahl der Komponenten, die wachsende Komplexität der einzelnen Komponenten und des Gesamtsystems und nicht zuletzt die Anforderungen ständig verbesserter Systeme machen es notwendig, die Einzelkomponenten sowie die Interaktionen mit immer mehr Funktionen auszustatten.

</p>

<div class="mw-heading mw-heading2"><h2 id="Herausforderungen_des_Embedded_Software_Engineering">Herausforderungen des Embedded Software Engineering</h2></div>

<p>Bei der Entwicklung von Software für eingebettete Systeme stehen Entwickler besonderen Randbedingungen gegenüber, deren Erfüllung notwendig für die korrekte Funktion ist. Dazu zählen die Kopplung zu physikalischen Prozessen, die damit einhergehenden Anforderungen an Zuverlässigkeit und die zunehmende Anzahl von verteilten Systemen mit hoher Dynamik.<sup id="cite_ref-Siemers_Gerstl_Grundlagen_ESE_2-0" class="reference"><a href="#cite_note-Siemers_Gerstl_Grundlagen_ESE-2"><span class="cite-bracket">[</span>2<span class="cite-bracket">]</span></a></sup>

</p>

<div class="mw-heading mw-heading3"><h3 id="Kopplung_an_physikalische_Prozesse">Kopplung an physikalische Prozesse</h3></div>

<p>Die physikalischen Prozesse, mit denen die eingebetteten Systeme gekoppelt sind und deren Wechselwirkungen durch die Software behandelt werden sollen, zwingen dem System ein vorgegebenes Zeitverhalten auf. Da sich die Zeitabläufe zum Beispiel bei gesteuerten Motoren nicht ändern lassen, muss das eingebettete System in <a href="Echtzeit" title="Echtzeit">Echtzeit</a> arbeiten, also in seinem zeitlichen Verhalten dem umgebenden technischen System angepasst sein.<sup id="cite_ref-Siemers_Gerstl_Grundlagen_ESE_2-1" class="reference"><a href="#cite_note-Siemers_Gerstl_Grundlagen_ESE-2"><span class="cite-bracket">[</span>2<span class="cite-bracket">]</span></a></sup>

</p><p>Hierbei wird zwischen hartem und weichem Echtzeitverhalten unterschieden. Die Differenzierung erfolgt dabei ausschließlich durch die Konsequenzen, die ein zeitliches Fehlverhalten hervorrufen kann: Stellt ein Fehlverhalten eine Gefährdung für Mensch und/oder Material dar, so darf es nicht vorkommen, und das System muss unter allen Umständen die zeitlichen Bedingungen erfüllen. Das wird als hartes Echtzeitsystem bezeichnet. Wird durch das Fehlverhalten lediglich eine Qualitätsminderung erzeugt, so wird von einem weichen Echtzeitsystem gesprochen.<sup id="cite_ref-Siemers_Gerstl_Grundlagen_ESE_2-2" class="reference"><a href="#cite_note-Siemers_Gerstl_Grundlagen_ESE-2"><span class="cite-bracket">[</span>2<span class="cite-bracket">]</span></a></sup>

</p><p>Andere Anpassungen an das physikalische System können beispielsweise die maximal erlaubte Verlustleistung, etwa aufgrund der maximal verfügbaren elektrischen Leistung oder der Begrenzung der erzeugten Wärme, oder die mittlere Energieaufnahme betreffen. Im Fall von batteriebetriebenen Geräten etwa bestimmt die mittlere Energieaufnahme die Einsatzdauer. Anpassungen an die elektrischen Werte können meist nur durch gemeinsame Hard- und Software Engineering (Co-Design) erreicht werden.<sup id="cite_ref-Siemers_Gerstl_Grundlagen_ESE_2-3" class="reference"><a href="#cite_note-Siemers_Gerstl_Grundlagen_ESE-2"><span class="cite-bracket">[</span>2<span class="cite-bracket">]</span></a></sup>

</p>

<div class="mw-heading mw-heading3"><h3 id="Zuverlässigkeitsanforderungen"><span id="Zuverl.C3.A4ssigkeitsanforderungen"></span>Zuverlässigkeitsanforderungen</h3></div>

<p>Die Zuverlässigkeitsanforderungen, die in besonderem Maße an eingebettete Systeme gestellt werden, betreffen die Hard- und Softwarequalität. <a href="Softwarequalit%C3%A4t" title="Softwarequalität">Softwarequalität</a> ist die Gesamtheit der Merkmale und Merkmalswerte eines Softwareprodukts, die sich auf dessen Eignung beziehen, festgelegte oder vorausgesetzte Erfordernisse zu erfüllen. Als Merkmale gelten Funktionalität, Zuverlässigkeit, Benutzbarkeit, Effizienz, Änderbarkeit und Übertragbarkeit.<sup id="cite_ref-Siemers_Gerstl_Grundlagen_ESE_2-4" class="reference"><a href="#cite_note-Siemers_Gerstl_Grundlagen_ESE-2"><span class="cite-bracket">[</span>2<span class="cite-bracket">]</span></a></sup>

</p><p>Die <a href="Reliabilit%C3%A4t" title="Reliabilität">Zuverlässigkeit</a> (englisch <i>reliability</i>) ist hierbei als Wahrscheinlichkeit definiert, dass ein System seine definierte Funktion innerhalb eines vorgegebenen Zeitraums und unter den erwarteten Arbeitsbedingungen voll erfüllt, das heißt intakt ist und es zu keinem Systemausfall kommt. Bei den Fehlern oder fehlerhaften Handlungen, die die Zuverlässigkeit herabsetzen, müssen zwischen der fehlerhaften Handlung (englisch <i>error</i>), die zu einem späteren Fehler führt, der fehlerhaften Stelle im Gerät oder Programmcode, auch als innerer Fehler (englisch <i>fault</i>) bezeichnet, und dem tatsächlichen Fehlverhalten, auch als Fehlerwirkung oder äußerer Fehler (englisch <i>failure</i>) bezeichnet, unterschieden werden.

Die Rate der äußeren Fehler wird in FIT (<i>Failure in Time</i>, Anzahl der auftretenden Fehler pro 10<sup>9</sup> Betriebsstunden) gemessen. Die durch Software verursachten Fehler übersteigen die Hardwarerate ohne besondere Maßnahmen um etwa 100 bis 1000.<sup id="cite_ref-gonzalez_3-0" class="reference"><a href="#cite_note-gonzalez-3"><span class="cite-bracket">[</span>3<span class="cite-bracket">]</span></a></sup> Hierin besteht eine wesentliche Aufgabe des Embedded Software Engineering, diese Rate auf die geforderten Werte zu reduzieren.<sup id="cite_ref-Siemers_Gerstl_Grundlagen_ESE_2-5" class="reference"><a href="#cite_note-Siemers_Gerstl_Grundlagen_ESE-2"><span class="cite-bracket">[</span>2<span class="cite-bracket">]</span></a></sup>

</p>

<div class="mw-heading mw-heading3"><h3 id="Verteilte_Systeme_mit_hoher_Dynamik">Verteilte Systeme mit hoher Dynamik</h3></div>

<p>Bei einer zunehmenden Anzahl von Systemen ist die Anzahl der (eigenständigen) elektronischen Komponenten sehr hoch, sie bewegt sich zwischen einigen 100 und über 1000 Komponenten. Entwicklungen wie Smart Sensors (Sensoren mit eingebauter Vorverarbeitung zum Beispiel durch Mikroprozessoren) oder <a href="Mikrosystem_(Technik)" title="Mikrosystem (Technik)">MEMS</a> (microelectromechanical system) zeigen, dass die Durchdringung eines physikalischen Prozesses mit elektronischen Komponenten zur Messung, Steuerung und Regelung sehr weitgehend sein kann und dass die Trennung physikalischer Prozess/Informationsverarbeitung nicht mehr aufrechterhalten werden kann.<sup id="cite_ref-Siemers_Gerstl_Grundlagen_ESE_2-6" class="reference"><a href="#cite_note-Siemers_Gerstl_Grundlagen_ESE-2"><span class="cite-bracket">[</span>2<span class="cite-bracket">]</span></a></sup>

</p><p>Die Probleme in der Softwareentwicklung solcher Systeme lassen sich durch zwei meist geforderte Eigenschaften darstellen: Zum einen soll eine solche verteilte Applikation robust, zuverlässig und in Echtzeit arbeitend sein, zum anderen arbeitet die verteilte Applikation hochgradig parallel, und das Gesamtsystem ist meist auch dynamisch, das heißt die Applikation muss sich den wandelnden Bedingungen anpassen. Die Kombination aus Verteilung, Zuverlässigkeit und dynamischer Anpassung gilt als besondere Herausforderung.<sup id="cite_ref-Siemers_Gerstl_Grundlagen_ESE_2-7" class="reference"><a href="#cite_note-Siemers_Gerstl_Grundlagen_ESE-2"><span class="cite-bracket">[</span>2<span class="cite-bracket">]</span></a></sup>

</p>

<div class="mw-heading mw-heading2"><h2 id="Ansätze_zum_Embedded_Software_Engineering"><span id="Ans.C3.A4tze_zum_Embedded_Software_Engineering"></span>Ansätze zum Embedded Software Engineering</h2></div>

<p>Neben der algorithmischen Korrektheit einer Applikation müssen bei eingebetteten Applikationen meist eine oder mehrere weitere Bedingungen eingehalten werden. Abgesehen von den grundlegenden Prinzipien des Software Engineering, die auch im eingebetteten Bereich zur Anwendung kommen, können zusätzliche Methoden zum Einsatz kommen, um diese Bedingungen zu erfüllen. Die Designmethoden unterscheiden sich dabei je nach zu erfüllender Bedingung.<sup id="cite_ref-Siemers_Gerstl_Grundlagen_ESE_2-8" class="reference"><a href="#cite_note-Siemers_Gerstl_Grundlagen_ESE-2"><span class="cite-bracket">[</span>2<span class="cite-bracket">]</span></a></sup>

</p>

<div class="mw-heading mw-heading3"><h3 id="Referenzmodell_für_eingebettete_Systeme"><span id="Referenzmodell_f.C3.BCr_eingebettete_Systeme"></span>Referenzmodell für eingebettete Systeme</h3></div>

<p>Bild 1 zeigt das allgemeine Referenzmodell eines nicht-verteilten eingebetteten Systems. Charakteristisch ist die starke Außenbindung mithilfe von Aktoren und Sensoren; sie stellen die wesentliche Kopplung an die technische Umgebung dar, in der das System eingebettet ist. Die Benutzerschnittstelle kann entfallen, in diesem Fall handelt es sich um ein tief eingebettetes System (englisch deeply embedded system). Die Referenzarchitektur zeigt, dass eingebettete Applikationen eine starke Eingabe/Ausgabe-(Input/Output-, I/O-) Bindung besitzen. Dementsprechend sind Hard- und Software stark I/O-dominant ausgeführt.<sup id="cite_ref-Siemers_Gerstl_Grundlagen_ESE_2-9" class="reference"><a href="#cite_note-Siemers_Gerstl_Grundlagen_ESE-2"><span class="cite-bracket">[</span>2<span class="cite-bracket">]</span></a></sup>

</p>

<div class="mw-heading mw-heading3"><h3 id="Designmethoden_zur_Erfüllung_zeitlicher_Vorgaben"><span id="Designmethoden_zur_Erf.C3.BCllung_zeitlicher_Vorgaben"></span>Designmethoden zur Erfüllung zeitlicher Vorgaben</h3></div>

<p>Die Echtzeitfähigkeit einer Software-Applikation ist die häufigste Bedingung, die erfüllt werden muss. Die Echtzeitfähigkeit bezieht sich dabei auf das Referenzmodell aus Bild 1, das heißt, das System muss im Allgemeinen auf Ereignisse von außen rechtzeitig reagieren. Die Rechtzeitigkeit besteht darin, dass eine maximale Zeit nach Eintreten des Ereignisses definiert ist, bei der die Reaktion eingetreten sein muss, unter Umständen auch eine minimale Zeit nach dem Ereignis, vor der die Reaktion nicht eintreten darf. Letzteres ist beispielsweise notwendig, wenn in einer eventuell verteilten Applikation mehrere Reaktionen gleichzeitig eintreten müssen.<sup id="cite_ref-Siemers_Gerstl_Grundlagen_ESE_2-10" class="reference"><a href="#cite_note-Siemers_Gerstl_Grundlagen_ESE-2"><span class="cite-bracket">[</span>2<span class="cite-bracket">]</span></a></sup>

</p>

<div class="mw-heading mw-heading4"><h4 id="Zeit-gesteuertes_Design">Zeit-gesteuertes Design</h4></div>

<p>Um die Kopplung zwischen Umgebungsereignissen und dem eingebetteten System herzustellen, bieten sich zwei Methoden an: Zeit-gesteuertes Design und Ereignis-gesteuertes Design. Das Zeit-gesteuerte Design (englisch time-triggered design) geht davon aus, dass es in der Software einen meist periodisch aufgerufenen Teil gibt, in dem das Vorliegen von Ereignissen festgestellt wird. Die Implementierung kann zum Beispiel durch einen periodisch per Timer ausgelösten <a href="Unterbrechungsanforderung" class="mw-redirect" title="Unterbrechungsanforderung">Interrupt Request</a> (IRQ) mit zugehöriger <a href="Unterbrechungsroutine" class="mw-redirect" title="Unterbrechungsroutine">Interrupt Service Routine</a> (ISR) erfolgen.<sup id="cite_ref-Siemers_Gerstl_Grundlagen_ESE_2-11" class="reference"><a href="#cite_note-Siemers_Gerstl_Grundlagen_ESE-2"><span class="cite-bracket">[</span>2<span class="cite-bracket">]</span></a></sup>

</p><p>Dieser zyklisch ablaufende Teil stellt das Vorliegen von Ereignissen fest und startet die entsprechende Reaktionsroutine. Die Zykluszeit richtet sich dabei nach der geforderten maximalen Reaktionszeit für dieses Ereignis sowie anderen Zeiten im System. Diese Designmethodik ergibt ein statisches Design, bei dem alle Aktivitäten zur <a href="%C3%9Cbersetzungszeit" title="Übersetzungszeit">Übersetzungszeit</a> (englisch compile time) bekannt sein müssen. Die Echtzeitfähigkeit dieses Designs lässt sich beweisen, wenn alle maximalen Bearbeitungszeiten (englisch worst-case execution time, <a href="Maximale_Laufzeit" title="Maximale Laufzeit">WCET</a>) und alle maximalen unterbrechungsfreien Zeiten (englisch worst-case interrupt disable time, WCIDT) bekannt sind.<sup id="cite_ref-Siemers_Gerstl_Grundlagen_ESE_2-12" class="reference"><a href="#cite_note-Siemers_Gerstl_Grundlagen_ESE-2"><span class="cite-bracket">[</span>2<span class="cite-bracket">]</span></a></sup>

</p>

<div class="mw-heading mw-heading4"><h4 id="Ereignis-gesteuertes_Design">Ereignis-gesteuertes Design</h4></div>

<p>Im Ereignis-gesteuerten Design (englisch event-triggered design) wird den Ereignissen selbst ein Interrupt Request zugewiesen. Das bedeutet, dass die zugehörigen Serviceroutinen zumindest teilweise als Interrupt Service Routine ausgelegt sein müssen, und ein Interrupt Priority Management muss die Prioritäten bei gleichzeitigem Auftreten regeln.

Das Gesamtsystem ist hierdurch scheinbar weniger belastet, weil die Ereignisbehandlung nur dann aufgerufen wird, wenn tatsächlich etwas vorliegt. Das System selbst kann jedoch im Vergleich zum Zeit-gesteuerten Design nicht schwächer ausgelegt werden, weil die Echtzeitfähigkeit garantiert werden muss. Die Systemauslegung eines (harten) Echtzeitsystems muss immer der maximalen Last folgen, nicht einer mittleren.<sup id="cite_ref-Siemers_Gerstl_Grundlagen_ESE_2-13" class="reference"><a href="#cite_note-Siemers_Gerstl_Grundlagen_ESE-2"><span class="cite-bracket">[</span>2<span class="cite-bracket">]</span></a></sup>

</p><p>Negativ am Ereignis-gesteuerten Design ist außerdem, dass die maximal definierte Ereignisrate nicht automatisch eingehalten werden muss. Zusätzliche Hardwaremaßnahmen sind erforderlich, falls – etwa durch <a href="Prellen" title="Prellen">prellende Schalter</a> oder Teilprozesse, die außerhalb der Spezifikation arbeiten – angenommene Ereignisraten überschritten werden können, um die Arbeitsfähigkeit der Applikation zu erhalten.<sup id="cite_ref-Siemers_Gerstl_Grundlagen_ESE_2-14" class="reference"><a href="#cite_note-Siemers_Gerstl_Grundlagen_ESE-2"><span class="cite-bracket">[</span>2<span class="cite-bracket">]</span></a></sup>

</p>

<div class="mw-heading mw-heading3"><h3 id="Designmethodik_für_verteilte_eingebettete_Systeme_mit_Echtzeitfähigkeit"><span id="Designmethodik_f.C3.BCr_verteilte_eingebettete_Systeme_mit_Echtzeitf.C3.A4higkeit"></span>Designmethodik für verteilte eingebettete Systeme mit Echtzeitfähigkeit</h3></div>

<p>Das Zeit-gesteuerte Design kann dahingehend verallgemeinert werden, dass ein synchrones Systemdesign gewählt wird. Dieses Systemdesign entspricht dem meist genutzten Modell der digitalen Hardware: Berechnungen werden durch ein (asynchrones) Schaltnetz durchgeführt und am Ende eines Zeittakts in Flipflops gespeichert. Übertragen auf das Softwaredesign heißt dies, dass algorithmische Berechnung und Kommunikation (vor oder nach der Berechnung) in einer angenommenen Zeitspanne durchgeführt werden und am Ende dieser Zeitspanne alle Ergebnisse als Eingang für den nächsten Zeitabschnitt gespeichert werden.<sup id="cite_ref-Siemers_Gerstl_Grundlagen_ESE_2-15" class="reference"><a href="#cite_note-Siemers_Gerstl_Grundlagen_ESE-2"><span class="cite-bracket">[</span>2<span class="cite-bracket">]</span></a></sup>

</p><p>Die synchrone Designmethodik ergibt dann eine Systemarchitektur, die der eines komplexen, kooperierenden Automaten entspricht. Für echtzeitfähige verteilte Systeme muss die Kommunikationszeit selbst begrenzt sein, was durch spezielle Netzwerke (zum Beispiel TTP/C, <a href="Time-Triggered_Protocol" title="Time-Triggered Protocol">Time-Triggered Protocol</a> Class C oder diverse Echtzeit-Ethernet-Standards) gewährleistet ist.

In der Entwicklung selbst muss dann die Annahme, dass die algorithmische Verarbeitung innerhalb einer vorgegebenen Maximalzeit erfolgt, nachgewiesen werden (<a href="Maximale_Laufzeit" title="Maximale Laufzeit">WCET-Bestimmung</a>).

Synchrone Sprachen, die die Entwicklung unterstützen, sind <a href="Esterel_(Programmiersprache)" title="Esterel (Programmiersprache)">Esterel</a>, <a href="Lustre_(Programmiersprache)" title="Lustre (Programmiersprache)">Lustre</a> und Signal. Zur Zeitlichen Definition des Systemverhaltens, insbesondere auch bei verteilten Systemen, bietet sich auch <a href="Timing_Definition_Language" title="Timing Definition Language">Timing Definition Language</a> (TDL) an.<sup id="cite_ref-Siemers_Gerstl_Grundlagen_ESE_2-16" class="reference"><a href="#cite_note-Siemers_Gerstl_Grundlagen_ESE-2"><span class="cite-bracket">[</span>2<span class="cite-bracket">]</span></a></sup>

</p>

<div class="mw-heading mw-heading3"><h3 id="Designmethoden_zur_Erfüllung_energetischer_Vorgaben"><span id="Designmethoden_zur_Erf.C3.BCllung_energetischer_Vorgaben"></span>Designmethoden zur Erfüllung energetischer Vorgaben</h3></div>

<p>Um energetische oder verlustleistungsbezogene Vorgaben zu erfüllen, existieren vergleichsweise wenig softwarebasierte Methoden. Die Auswahl eines <a href="Mikrocontroller" title="Mikrocontroller">Mikrocontrollers</a> anhand der energetischen Eigenschaften oder sogar der Wechsel auf anderen programmierbare Architekturen wie <a href="Field_Programmable_Gate_Array" title="Field Programmable Gate Array">Field Programmable Gate Arrays</a> (FPGA) können hier wesentlich energiesparender wirken als reine Softwarelösungen.

Innerhalb des Softwaredesigns können drei Methoden zur Senkung des Energiebedarfs und der Verlustleistung angewendet werden:<sup id="cite_ref-Siemers_Gerstl_Grundlagen_ESE_2-17" class="reference"><a href="#cite_note-Siemers_Gerstl_Grundlagen_ESE-2"><span class="cite-bracket">[</span>2<span class="cite-bracket">]</span></a></sup>

</p>

<ol><li>Die tatsächliche Laufzeit des Programms pro betrachteter Zeiteinheit wird möglichst minimal gestaltet, und in den Zeiten, in denen der Prozessor idle ist, wird der Betriebszustand „schlafend“ oder ähnlich gewählt. Dieser Betriebszustand (der Hardware) ist dadurch gekennzeichnet, dass viele Teile des Prozessors abgeschaltet sind und dadurch der Energieumsatz stark minimiert wird. Wie weitgehend abgeschaltet werden kann und wie der Prozessor wieder aufgeweckt wird, kann nur im Einzelfall entschieden werden und ist abhängig von dem Prozessortyp, der Planbarkeit der Applikation und so weiter.</li>

<li>In einem anderen Ansatz wird versucht, das Programm so zu gestalten, dass bei Einhaltung aller Zeitschranken möglichst gleiche <a href="Leerlaufprozess" title="Leerlaufprozess">Idle</a>-Zeiten (pro betrachteter Zeiteinheit) entstehen. Im zweiten Schritt kann dann die Taktfrequenz des Prozessors (und damit auch die Betriebsspannung) so angepasst werden, dass keine Idle-Zeiten mehr existieren. Das liefert ein gleichförmig arbeitendes Design mit minimierter Verlustleistung. Die ideale Zeiteinheit, deren Ablauf optimiert wird, ist dabei die Superperiode (= kleinstes gemeinsames Vielfaches über alle verschiedenen periodischen Abläufe im System), die Anpassung der Taktfrequenz muss jedoch für jede einzelne Periode möglich sein.</li>

<li>Alternativ oder zusätzlich können auch spezialisierte <a href="Compiler" title="Compiler">Compiler</a> verwendet werden, die energetisch besonders günstigen Code liefern. So ist der Bedarf an elektrischer Energie für verschiedene Instruktionen unterschiedlich, das kann ausgenutzt werden.</li></ol>

<div class="mw-heading mw-heading2"><h2 id="Literatur">Literatur</h2></div>

<ul><li>Christian Siemers, Sebastian Gerstl: <a rel="nofollow" class="external text" href="https://www.embedded-software-engineering.de/grundlagen-des-embedded-software-engineering-a-855039/"><i>Grundlagen des Embedded Software Engineering.</i></a> In: <i>Elektronikpraxis.</i> (<span class="-print"><a href="Internationale_Standardnummer_f%C3%BCr_fortlaufende_Sammelwerke" title="Internationale Standardnummer für fortlaufende Sammelwerke">ISSN</a> <span style="white-space:nowrap"><a rel="nofollow" class="external text" href="https://zdb-katalog.de/list.xhtml?t=iss%3D%220341-5589%22&key=cql">0341-5589</a></span></span>) Bd. 55 ??, H. 17 ?? (11. August 2019), S. ?? (print+ePaper), ePaper: Website abgerufen am 18. Februar 2022.</li>

<li>Shankar Sastry, Janos Szipanovitis, Ruzena Bajcsy, Helen Gill: <i>Model-based design of embedded systems: Scanning the issue.</i> In: <i>Proceedings of the IEEE.</i> (<span class="-print"><a href="Internationale_Standardnummer_f%C3%BCr_fortlaufende_Sammelwerke" title="Internationale Standardnummer für fortlaufende Sammelwerke">ISSN</a> <span style="white-space:nowrap"><a rel="nofollow" class="external text" href="https://zdb-katalog.de/list.xhtml?t=iss%3D%220018-9219%22&key=cql">0018-9219</a></span></span>) Bd. 91, H. 1 (Januar 2003), S. 4–10.</li>

<li>Christian Siemers: <i>Echtzeit: eine kleine Geschichte der Zeit.</i> In: <i>Elektronikpraxis.</i> (<span class="-print"><a href="Internationale_Standardnummer_f%C3%BCr_fortlaufende_Sammelwerke" title="Internationale Standardnummer für fortlaufende Sammelwerke">ISSN</a> <span style="white-space:nowrap"><a rel="nofollow" class="external text" href="https://zdb-katalog.de/list.xhtml?t=iss%3D%220341-5589%22&key=cql">0341-5589</a></span></span>) Bd. 43, H. 23 (20. November 2007), S. 42–43.</li></ul>

<div class="mw-heading mw-heading2"><h2 id="Weblinks">Weblinks</h2></div>

<ul><li><a rel="nofollow" class="external text" href="http://www.ese-report.de/">Deutschsprachiges Online-Fachmagazin zu Embedded Software Engineering </a></li>

<li><a rel="nofollow" class="external text" href="http://www.ese-kongress.de/">Deutscher Embedded Software Engineering Kongress</a></li>

<li><a rel="nofollow" class="external text" href="http://www.elektronikpraxis.vogel.de/themen/embeddedsoftwareengineering/analyseentwurf/articles/98363/">Prof. Dr. Christian Siemers: Eine kleine Geschichte der Zeit</a></li></ul>

<div class="mw-heading mw-heading2"><h2 id="Einzelnachweise">Einzelnachweise</h2></div>

<li id="cite_note-balzert-1"><span class="mw-cite-backlink"><a href="#cite_ref-balzert_1-0">↑</a></span> <span class="reference-text">Helmut Balzert: <i>Lehrbuch der Software-Technik.</i> Band 1: <i>Software-Entwicklung.</i> 2. Aufl., 1. Nachdr., Spektrum Akademischer Verlag, Heidelberg 2001, ISBN 3-8274-0480-0, S. 36.</span>

</li>

<li id="cite_note-Siemers_Gerstl_Grundlagen_ESE-2"><span class="mw-cite-backlink">↑ <sup><a href="#cite_ref-Siemers_Gerstl_Grundlagen_ESE_2-0">a</a></sup> <sup><a href="#cite_ref-Siemers_Gerstl_Grundlagen_ESE_2-1">b</a></sup> <sup><a href="#cite_ref-Siemers_Gerstl_Grundlagen_ESE_2-2">c</a></sup> <sup><a href="#cite_ref-Siemers_Gerstl_Grundlagen_ESE_2-3">d</a></sup> <sup><a href="#cite_ref-Siemers_Gerstl_Grundlagen_ESE_2-4">e</a></sup> <sup><a href="#cite_ref-Siemers_Gerstl_Grundlagen_ESE_2-5">f</a></sup> <sup><a href="#cite_ref-Siemers_Gerstl_Grundlagen_ESE_2-6">g</a></sup> <sup><a href="#cite_ref-Siemers_Gerstl_Grundlagen_ESE_2-7">h</a></sup> <sup><a href="#cite_ref-Siemers_Gerstl_Grundlagen_ESE_2-8">i</a></sup> <sup><a href="#cite_ref-Siemers_Gerstl_Grundlagen_ESE_2-9">j</a></sup> <sup><a href="#cite_ref-Siemers_Gerstl_Grundlagen_ESE_2-10">k</a></sup> <sup><a href="#cite_ref-Siemers_Gerstl_Grundlagen_ESE_2-11">l</a></sup> <sup><a href="#cite_ref-Siemers_Gerstl_Grundlagen_ESE_2-12">m</a></sup> <sup><a href="#cite_ref-Siemers_Gerstl_Grundlagen_ESE_2-13">n</a></sup> <sup><a href="#cite_ref-Siemers_Gerstl_Grundlagen_ESE_2-14">o</a></sup> <sup><a href="#cite_ref-Siemers_Gerstl_Grundlagen_ESE_2-15">p</a></sup> <sup><a href="#cite_ref-Siemers_Gerstl_Grundlagen_ESE_2-16">q</a></sup> <sup><a href="#cite_ref-Siemers_Gerstl_Grundlagen_ESE_2-17">r</a></sup></span> <span class="reference-text">Christian Siemers, Sebastian Gerstl: <a rel="nofollow" class="external text" href="https://www.embedded-software-engineering.de/grundlagen-des-embedded-software-engineering-a-855039/"><i>Grundlagen des Embedded Software Engineering.</i></a> In: <i>Elektronikpraxis.</i> (<span class="-print"><a href="Internationale_Standardnummer_f%C3%BCr_fortlaufende_Sammelwerke" title="Internationale Standardnummer für fortlaufende Sammelwerke">ISSN</a> <span style="white-space:nowrap"><a rel="nofollow" class="external text" href="https://zdb-katalog.de/list.xhtml?t=iss%3D%220341-5589%22&key=cql">0341-5589</a></span></span>) Bd. 55 ??, H. 17 ?? (11. August 2019), S. ?? (print+ePaper), ePaper: Website abgerufen am 18. Februar 2022.</span>

</li>

<li id="cite_note-gonzalez-3"><span class="mw-cite-backlink"><a href="#cite_ref-gonzalez_3-0">↑</a></span> <span class="reference-text">Antonio González, Scott Mahlke, Shubu Mukherjee, Resit Sendag, Derek Chiou, Joshua J. Yi: <i>Reliability: Fallacy or reality?</i> In: <i>IEEE Micro.</i> (<span class="-print"><a href="Internationale_Standardnummer_f%C3%BCr_fortlaufende_Sammelwerke" title="Internationale Standardnummer für fortlaufende Sammelwerke">ISSN</a> <span style="white-space:nowrap"><a rel="nofollow" class="external text" href="https://zdb-katalog.de/list.xhtml?t=iss%3D%220272-1732%22&key=cql">0272-1732</a></span></span>) Bd. 27, H. 6 (November 2007), S. 36–45.</span>

</li>

</ol></div><div><div class="zim-footer">

Dieser Artikel wurde von <a class="external text" title="Zuletzt bearbeitet am 2025-12-03" href="https://de.wikipedia.org/wiki/?title=Embedded_Software_Engineering&oldid=262086489">Wikipedia</a> herausgegeben. Der Text ist unter <a class="external text" href="https://creativecommons.org/licenses/by-sa/4.0/deed.de">Creative Commons Attribution-Share Alike 4.0</a> verfügbar, sofern nicht anders angegeben. Für die Mediendateien können zusätzliche Bedingungen gelten.

</div>

</div></div>

</div>

</main>

</div>

</body></html>